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I- LS TROD OCT ID 

In the past two decades, as computer hardware costs have 
fallen and software costs have risen, there has been an 
increasing interest in prog rammer productivity. This 
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astronomical growth in the computer software industry, 
finding sufficient numbers of well trained and experienced 
programmers is prohibitively difficult. [Ref. 2], According 
to Digital Equipment Corporation * Ref. 3], the biggest 
problem is identifying the few good programmers. Of the 
many applicants they receive, most are not capable of 
writing sophisicatea software. Consequently, software 
developers are turning towards increasing the productivity 
of programmers in an attempt to keep pace with the demand 
for current and future software design needs. 
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There have been a number of papers written discussing 
productivity. Some discuss determinants of programming 
productivity [Ref. 2], others provide tools [Ref. 4], which 
purport to improve productivity. Interestingly, few of 
these studies discuss or make reference to others who have 
discussed how to actually measure this productivity. The 
philosophical approach foe many years was that programming 
was an art. This made it virtually impossible to measure, 
for it would be similar to measuring the progress or produc- 
tivity of a Picasso or Michelangelo as he was painting or 
sculpting. Obviously, there is 10 way to measure the 
progress of art aside from personal opinion. This, however, 
is not acceptable in an industry based on the profit motive. 
In the late 1960's the term "Software Engineering" was 
coined and with it came a number of ideas that served to 
pull programming out of the world of art and into the world 
of the engineer, a worLd where measurement is of vital 
importance. Software development was shown to be an area 
that required discipline and a process-oriented approach 
[Ref. 5]. 

Software engineering has grown through the 1970's to 
virtually become the rule for the management of programming. 
It has led to the development of new strategies for software 
development. These strategies, top-down design, bottom-up 
design, structured prgramming, modular decomposition and 
metaprogramming, have provided a better foundation from 
which software developers can attempt to meet the growing 
demand for soft-ware products. Although these development 
techniques have made software development easier and helped 
tc control the cost growth, they have had little impact on 
productivity measurement. 

To discuss the measuring of software development or 
programming productivity, one must first determine what the 
product is. From the first day of programming until the 
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present, the predominant product of discussion has been tha 
"line of code" (LOC) . This is the product on which nearly 
all research and the database information are based. If one 
were a construction engineer one would not discuss a 
building or bridge based on tha number of bricks and girders 
used. Instead, rooms or floors or spans might be much mors 
appropriate. These itams are integral but separately 
measureable components of the final product. So why, 
rhetorically, do researchers and data base information 
collectors continue to insist on LOT measures instead of an 
integral and separately measureable and meaningful component 
of software engineering? This not a question for this paper 
to answer but one for the reader to consider when planning 
his own research or data base collection. 

The Fleet Material Support Office (FMSO) is experiencing 
the same problems as the rest of the software indusrty. It 
is faced with a huge demand for quality software from the 
organizations it is tasked to support. The tasking of the 
past five years is shown in Figure 1.1 below. These figures 
are only for the Central Design Agency, the primary mission 
of FMSO. The figures show an increase in FMSO maintained 
programs of 75.4 percent in this short period. These 
figures are expected to continue to rise at a significant 
rate as the Ravy continues to automate more and more func- 
tions. Another problem facing FMSO is the salaries of the 
programmers. According to Business Seek [Ref. 5] programmer 
salaries are rising at a rate of 15 percent annually and 
salaries for top systems analysts can reach $50,000 a year. 
This places an extreme burden on the personnel department to 
acquire top personnel when hiring new programmers and 
systems analysts. The productivity issue becomes 

increasingly critical foe FMSO in the light of the hiring 
freeze imposed during the Carter administration and the 
drive to reduce the cost of government in the present Reagan 
administration. 
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CD A Program Growth 



FY 

77 XXXXXXXXX 5,389 

78 XXXXXXXXXXXXX 6,423 

79 XXXXXXXXXXXXXXXXXX 7,722 

80 XXXXXXXXXXXXXXXXXXXX 7,938 

81 XXXXXXXXXXXXXXXXXXXXX XXXXX 9,330 

82 XXXXXXXXXXXXXXXXXXXXX XXXXXXXXX 9 ,454 (April) 



Figure 1.1 FHSO Program Library Growth. 

This paper attempts to present a number of issues 
related to the measuring of programmer productivity. It 
will show that there are a other factors that impact on how 
ore interprets the productivity figures. The manager needs 
to realize there are several different levels of the organi- 
zation, each with its own product or set of products. 
Therefore, each level has a productivity rating for which it 
must be responsible. In fact, the reader should note that 
the programmer is not the predominant link in the output of 
a programming project. The requirements of the Department 
of Defense and conscientious software developers throughout 
the industry has placed increasing importance on the relia- 
bibiity and maintainability of software. This new emphasis 
has produced a whole array of corresponding products which 
must be accounted for and new productivity levels which must 
be examined. 
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II. WHOSE PRODUCT IS BEING MEASURED? 

When discussing productivity, before one can consider 
who to measure, one must first determine what the product is 
and then who makes the product. Without a rational visuali- 
zation of the product it is unintelligent to discuss the 
ability of a person's, group's or machine's ability to 
deliver that product. Depending upon the level of the 

organization at which one looks there will be a variety of 
goals, objectives and products. Both Kiser [Ref. 7, p. 244] 
and the IEEE Workshop on Software Productivity [Ref. 8] 
address this important issue. 

Where the IEEE Workshop focused on the general area of 
productivity, Kiser was most concerned with software manage- 
ment productivity. She focused on the idea that the manager 
often has as much to do with a programmer's productivity as 
does the programmer himself or his tools. This is a nontri- 
vial issue. She looked at the top three levels of 
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Figure 2.1 Kiser 
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Many managers have failed 
being well-trained and 
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provided with excellent tools, continue to produce at unsa- 
tisractory levels. Quite often, from this researcher's 
experience and the experience provided by Kiser, the poor 
production level is caused by higher level managerial poli- 
cies or actions. This can be understandable when one 
examines the concerns of the various management levels. 

At the corporate level, top management is usually 
concerned with profit maximization and market share. FMSO, 
being part of the public sector, does not have this parti- 
cular concern but there are comparable goals ( Figure 2.2 ) 

CENTRAL DESIGN AGENCY ( CDA) 

RETAIL NAVY STOCK FUND 
OPERATIONS ANALYSIS 
SUPPLY OPERATIONS SUPPORT 
I NTERN AT I ONAL LOGISTICS 

i j 



Figure 2.2 FMSO Major Mission Areas. 

which are fleet support and effective management of their 
approximate S3. 3 billion, PY82, procurement authority. When 
one considers the impact of money management at this level 
it is understandable that concerns for indiviual programmer 
productivities can get Lost. The interpretation of top 
level management polices oy lower Level managers can also 
affect productivity. 

At the middle management level, managers become 
concerned with specific product development and resource 
allocation. For FMSO, in its primary mission area as a CDA, 
management is concerned v itk allocation of resources to 
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Figure 2.3 FMSO Z DA Primary Product Areas. 

respective product areas as shown in Figure 2.3 below. The 
allocation of the resources is tempered with the command 
goals and the budget provided by the various sponsors. 

The first line level of management, project management, 
is where one first encounters the edge of software produc- 
tivity, the area with which this paper is concerned. Here 
the project manager is concerned rfith meeting prescribed 
milestones within budget. The products at this level are 
the various "deliverables", such as functional specifica- 
tions, conceptual designs, program design, test plans, etc., 
that are required in an effectively managed project with 
milestone requirements. These are the products one must 
measure against their respective costs. 
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At the line level itself there ere two groups, project 
teams and the individuals who make up the teams. The team 
must be measured against its ability to deliver integrated 
software products. The individuals must be measured against 
their ability to deliver specific portions of the team 
assignment. This is the point where programmer productivity 
is discussed by most researchers. A special note is 
required at this point. While one usually assumes that the 
delivered products are of a specific quality, this seems to 
be missed quite often when discussing programmer products. 
The idea of quality in the product must always be consid- 
ered. A person who can deliver five programs in one day 
that are incorrect or do not provide consistent results is 
not nearly as productive as one who delivers one product 
every five days but which is correct and easily maintained. 
Very few productivity measures take quality into 

consideration, as will be shown later . 

After realizing the various products made by different 
levels in the organization, one must then consider who is 
viewing these measures, management or labor. The views and 
concerns of each are usually quite different unless there 
has been a considerable amount of education on each side. 

Management must understand there is an overhead expense 
to developing, collecting and analyzing productivity 
measures which must be justified. Intuitively, one must 
have a set of measures before one can determine constant, 
"normal" or changing productivity. Also management needs to 
know how it intends to use these measures. The IEEE 
[Ref. 8, p. 341] sees four major uses for productivity 
measures: 1) motivation; 2) understanding; 3| evaluation; 

and 4) management. 

Productivity measures can be used for motivational 
purposes in three ways which provide tangible benefit. 
First, researchers [Ref. 9,] have shown that by paying 
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attention to a person or group, performance levels of that 
person or group will improve or change to what the observes 
perceives as expected performance. This is known as the 
Hawthorne Effect. When managers take the time to do produc- 
tivity studies the Hawthorne Effect may occur, albeit 



temporarily. Second is 


the ability to 


focus 


attention 


on 


desir ed behaviors, events and objects 


or products. 


The 


measures selected will 


place relative 


importance on 


the 


areas being measured. 


? or instance. 


if a 


series 


of 



measures are selected which include speed of production and 
maintainability the perceived relation between them by the 
programmer will determine which measure they emphasize. 
That perception of relative importance can have a profound 
effect on the final product. If programmers see speed being 
rewarded or emphasized more than maintainability, the 
manager should expect to see programs produced rapidly but 
which are hard to understand and have little documentation. 
If the reverse is perceived, then the manager should expect 
to see longer programming times with much easier to under- 
stand and better documented code. The third motivating 
factor occurs through feedback of results. The effective 
feedback of productivity measures can lead to changes in 
performance in several ways. Quite often performance will 
improve through the personal pride in accomplishment or 
competition with p«ers. Also if a corresponding and 
effective rewards and penalty system, either formal or 
informal, exists, performance normally will follow the 
system correspondingly. 

Second, productivity measurements help managers to 
understand the factors underlying productivity. Measurement 
is fundamental to science in that it forces managers and 
researchers to conceptualize the area under study. Using 
various concepts will determine which measures to use as 
managers continue to try to model tie environment in which 
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they operate. Failure to develop a model will hinder 
managers in improving performance and will keep software 
development an art instead of a 'science. 

Third, productivity measures help managers evaluate 
performance because they quantify performance. It is easier 
to evaluate performance over time within a single group or 
organization because the measures remain constant. It is 
also very important to track performance so that proper 
feedback to personnel can be provided. It is also important 
to evaluate between groups to see how one stands against, an 
industry average. This has proven to be particularly diffi- 
cult for software developers. Few groups use the same 
measures. Those that use similar sounding measures often 
have significantly different definitions for the individual 
parts of the measure. L3I , which will be discussed later, 
is a most common area of disagreement. Nevertheless, it is 
important for each organization to establish a baseline and 
to build a database of information. This information can 
then be used for measuring the evolution of methodologies 
and technologies used in software development. 

Fourth, productivity measurement imposes a managerial 
discipline. Normally managers are concerned with tracking 
progress against a schedule and budget. The consistent use 
and taking of measurements can be extremely helpful in 
making projections of progress against schedules and 
budgets. The manager must remember that a productivity 
measure is only a snapshot. It must be analyzed in relation 
to its environment. In particular, managers must realize 
the difference in the learning curves of various projects. 
k "f irst-of-its-kind" project will have a much different 
learning curve than a simple modification to a generic 
project. The pr oducti'/i ty rates will normally change 
proportionally to the learning curve. 
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The manager's need for measures and his goals can differ 
significantly frcm those of the workforce. Management often 
wants to use the measures to identify exceptional perform- 
mers or those who need added training. 

The workforce, however, may view the measures as a way 
to generate either more products from the same work effort 
or to generate the same number of products from a reduced 
workforce. When the workforce sees the second side there 
can be severe implications, particularly if they are 
organized. 

The workforce will rapidly wonder what their benefits 
will be from all this new attention. Will the measures lead 
to more money for the same hours, the same money for less 
hours for the good pecformmers and/or lost jobs for the 
poorer ones? In an effort at job preservation, productivity 
may fall or stagnate at a predetermined level. This 
researcher has seen deliberate productivity stagnation by 
bricklayers, both in the housing and steel industries, and 
by electricians working for a telephone company, all at well 
below reasonable levels of capability. For one to think 
that programmers and their industry would not tend to act in 
a similar fashion is to approach this area with tunnel 
vision. This may become a primary concern for FMSO where 
some of their government employees aold specific 3S ratings 
and incomes based on the number of personnel they manage. 
Command level management must take care in the introduction 
of the productivity metrics so that personnel in these 3S 
ratings do not feel that their jobs or ratings are in 
jeopardy if there is significant increase in productivity 
which leads to a reduction in force (RIF) . 
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III. WHAT IS THE PR3D0CT? 



This researcher has determined that the predominant 
measure of programmer productivity is the quantity of lines 
of code written. This leads to several interesting conclu- 
sions. First, the programmer only writes deliverable code. 
Second, the programmer is the single dominant entity in 
software development. Aid third, there are no other rele- 
vant products or by-products in a software development 
project. Anyone who has the opportunity to study or to 
work in the software development arena realizes the fallacy 
of these conclusions. Programmers do considerably more than 
write deliverable cods. There are many other people 
involved, each adding important contributions to the 
project. There are several equally important products. 

From the previous chapter it was noted that there are 
Qany levels of an organization whose productivity should be 
measured. Those involved in software development realize 
that various levels of tie organization make contributions 
to the various products of each project. This chapter will 
look at the different products that this researcher feels 
are relevant to the measure of software development produc- 
tivity. This discussion will begin with middle level 
management and work towards the individual. As we progress 
down the organization the product will become easier to 
grasp. The span of management control and resource resoon- 
sioilities will decrease. Therefore, one must remember to 
ensure the product and the level of the organization match. 
All too often people ace evaluated on their ability to 
produce a product which they were not assigned to produce 
nor had any role in producing. 
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Unfortunately the reader will find in this section 
several terms that have multiple meanings. This is inesca- 
pable because there has been no accepted set of standard 
definitions within the software development industry. 

A. PROJECTS AS PRODUCTS 

The "contracted project", genetically, is a software 
development tasking for which an organization contracts 
another to produce. It may consist of a number of sub- 
projects or programs. An example is the development of an 
operating system which includes a job scheduler, process 
scheduler and file manager, figure 3.1 shows the various 
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Figure 3.1 Software Development Products. 

component products of a project. The project, an operating 
system, must integrate each of these various parts to be 
complete. Therefore, tae question of productivity here is 
whether or not the project can be delivered on budget and on 
sch ed ule . 
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If the contracted project is large, as in the operating 
system example, it will be broken down into several smaller 
projects, which I call "assigned projects" since there is 
little choice as to who will manage them once the contracted 
project is accepted. The assigned projects will be given to 
several project managers who will report to the central 
contracted project manager. The role of each of these 
project managers is to deliver a fully complete integrated 
operating product. 

The question at this point is, "Are these good items by 
which to measure productivity?". yes, they are, for several 
reasons. First, for this level of ma nagem ent they are the 
only products that are produced. Second, the reason for the 
manager to hold the particular job of project manager is for 
him/her to deliver a project on time, withii^ budget and to 
the satisfaction of the customer sc that the organization 
may make its profit. What about the difference in languages 
used or the sizes of various projects? These questions need 
to take their rightful place in the data base of information 
of the ccrpcration. Eaca productivity measure has a set of 
parameters within which it can only be used. There is a 
definite need to know how capable a project manager is at: 
1) developing any project; 2) using a specific language; 3) 
developing various sized projects; '4) developing machine 
dependent projects; 5| developing f irst-of -its-kind 
projects; or 6) modifying a generic project. 

Each of these parameters gives added insight to a 
project manager's productivity rating. The first lets one 
know hew productive he/she is relative to all the other 
project managers regardless of project specifics. Each of 
the other measures provide additional information on the 
relative productivity of a project manager within the diffe- 
rent parameters. Use of all of these productivity ratings 
by the next higher level of management may improve both 
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levels of management's productivity provided project 
managers are well matched to projects where their 
productivity is highest. 

B. MILESTONES AND MANAS EME NT/SOPPDBT 

At this point it may be advantageous to discuss a 
management tool that many may consider to be or confuse 
with, a product. A "milestone" is a point in the life of a 
development project when a deliverable product, as listed in 
Figure 3.1 , should be completed. Many would think that the 
ability to meet project milestones shows great productivity. 
This is not true. For if it were true, first the milestone 
must, in fact, mean the production of a deliverable item. 
Second, the deliverable item must be something of value to 
the project. If the deliverable is, in fact, of significant 
value to the project then the production of that item is the 
basis for one's measure and not the meeting of a milestone. 
The meeting of the milestone shows only that the project is 
proceeding as planned. The milestone has no other inherent 
value. That is, one does not deliver a milestone as one 
would a program. The milestone is only another management 
tool just as is a productivity measure. 

Like milestones, Manag a ment/Support is not a product but 
a management tool. However, the type, quality and quantity 
of the support must be considered very carefully. 
Manag emer.t/suppo rt exacts a price in that it is an overhead 
expense. Its value is not as a product but as a tool. 
Nearly ail presentations discussing productivity refer to 
the management/support tools. This is where the vendors and 
consultants make a great deal of money. They speak of 
productivity improvement and the aids that provide it. 



21 



There are two parts to this concept, management tools 
and support tools. The management side deals with systems 
that help predict costs and time schedules and those that 
track the progress against the predictions and plans. At 
FM50, this function is under the auspices of the Management 
Department, Code 92 [Ref. 10] where PAC-II is used to track 
and DOD MICRO and SLIM are used to estimate software costs 
and time schedules. The value of this support can be very 
subjective. Often the value of the management aid is that 
in gives the manager much more confidence in his/her deci- 
sions. The effect of the use of these kinds of tools may 
also be seen on the ledger. If the systems help management, 
all else being equal, one would expect to see fewer cost 
overruns and better personnel management. 

The support side has a miriad of tools that predict 
sure-fire ways to improve productivity dramatically. These 
tools include various design procedures (i.e. structured, 
top-down, modular design), on-line programming and provision 
for each programmer to have his/her own CRT terminal to 
mention a few. T.C. Jones [Ref. 11] discusses more of these 
tools and their respective limitations. 

The fact that management/support is not a product does 
nor minimize its importance. On the contrary, it is vital 
tc effective software development. But the manager must 
realize that the addition of each piece of management/ 
support costs mcney for which amounting muse be made. 
Although, there are many management/support systems which 
may improve productivity, the indiscriminate implementation 
of their use will not necessarily lead to productivity 
improvements. The use and expansion of management/support 
is an area worthy of further study. 
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C. DESIGN AND FUNCTIONAL SPECIFICATIONS 



Design specifications are usually thought of as a 
product cf the contracting organization. They are used as 
the basis from which to make a contractual bid and to write 
the functional specifications. However, the design specifi- 
cations, as delivered, often must be rewritten by the 
contractor in close conjunction with the contracting organi- 
zation so that they are explicit enough to properly write 
the functional specifications. 

Both Keider [Bef. 12] and Howien [Bef. 13] discuss the 
need for well thought out and well written design specifica- 
tions. Keider ' s article, "Why Projects Fail", shows how 
poorly planned projects waste money ana resources. Howden's 
article, "Life-Cycle Software Valuation", discusses the 
need for project design specifications to meet five proper- 
ties. First, the specif ications must be consistent 
internally as well as in any related documents or other 
portions of the project. Second, the specifications must be 
complete. They must be examined for missing or incomplete 
information requirements and to ensure data properties are 
included. Third, the specifications should only include 
necessary items without redundancy (not to be confused with 
hardware redundancy to ensure reliability). Fourth, the 
system must be feasible with existing technology and hard- 
ware. And fifth, the specifications must use correct math 
formulas and decision tables. 

The reader should recognize that the validation of 
design specifications and functional specifications is a 
nontrivial task. The systems analysts who validate the 
design specifications and who write and validate the func- 
tional specifications must be held accountable for their 
resource use in the production of these products. The 
specifications need to be examined carefully, as discussed 
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above, especially when one considers that approximately 
forty percent of a projects resources are used in the design 
phase [Ref. 37]. Poor quality here is very difficult and 
costly to try to overcome later in the software development 
cycle . 



D. LIHES OF CODE AS A PRODUCT 

The line-of-code (LOC) is, by far, the predominant 
measure used throughout industry to discuss program size and 
productivity ratings for all levels of software development. 
Interestingly, though the entire industry uses LOC as a 
measure of product definition, few agree as to what a LOC 
is. One of the first questions asiced is, "Do you mean a 
line of object cede or source code?". The industry has had 
some success in distinguishing between them but not in 
choosing one or the other as a universal measure. Source 
code is that written by the programmer while object cods is 
the compiled code stored in memory. Source code is more 
often used to describe programmer productivity than object 
code which is usually used to define the quantity of 
computer memory required to score the program code 
[Ref. 14]. 

Assuming one has settled on source code as a part of the 
measure, what determines a line of code? Some have said 
each line or statement written by the programmer regardless 
of length. Others try to force the line to have eighty 
characters. Still others try to define it by statement 
punctuation characters by language (i.e. periods in COBOL or 
semicolons in PASCAL). 

If this weren't bad enough, the next question is, 
"<mich of the lines are 'countable'?". That is, some want 
to differentiate between executable statements, data decla- 
rations, comments, nendeliv erable debugging or testing aids, 
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ere. Use of LOC each of these areas must be explicitly 
defined because studies have shown line count variations of 
more than two-to-one on the same program [Ref. 15]. 

After the LOC is well defined and published, one must 
warch carefully because, just as the measure helps manage- 
ment to rate personnel, so does it help personnel to promote 
themselves, often by manipulating rhe rules in their favor. 
Here are several examples. 3ne company settled on every 
line written regardless of length. After some examination 
of several programs, lines were found not to be complete 
statements nor eighty characters in length, thus padding the 
true productvity levels. Another may decide to use eighty 
characters as the defined line. In this case it would not 
be unusual to find variables with extremely long names or 
use of the "blank" character tc fill up lines and thus pad 
the productivity rating. Paradoxically, the programmers may 
be forced to have large numbers of blank characters if 
management requires the use of structured programming tech- 
niques. Another problem is that programmers may fight the 
use of higher level languages so they may program in a 
language in which they are comfortable and which requires 
more lines to accomplish the same task. Jones [Ref. 15, 
p.dl-43] discusses the LDC measure more extensively than 
presented here. 

Since the measure is so difficult to define and may lead 
to unacceptable programming practices, as stated above, or 
cause paradoxical conclusions, as discussed in the following 
chapter, this researcher feels LDC is a poor product 

measure. However, this does not mean to say that there is 

no use for LOC as a product measure. In fact it is the only 
measure available when one is performing maintenance on 
programs which entails changing individual lines in a 
program. Therfore, we must have a definition for a LOC. 
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There are many diffacent languages in which one 
program. Since each has its own rules of construction the 
definition of a LOC will necessarily be different for each 
language. This researcher prefers to view a line of code in 
the context of a complete sentence or phrase of spoken 
language. Each programming language has a defined equiva- 
lent of a complete statement or phrase. Just as Hemingway 
and Faulkner had different styles of conveying information, 
so will programmers. This is not a detriment to programming 
any more than it is to writing. Programmers will settle 
into standard line lengths with which each is comfortable. 
As long as management is satisfied that the style fits well 
into the structure of the language then there should be no 
problem. This does require management to supervise and to 
train those that are not consistent in their own programming 
or are far from the "average" iine length of the rest of the 
programmers . 

The countable lines should be those that are vital to 
the program quality and specific language. The lines that 
are niceties but which aid in the readability of programs 
have good reason to be in programs. They should be counted 
but not with full credit. The comment line is an example. 
It is necessary for readability but a one hundred line 
program does not need an additional hundred lines of 
comments. Contrarty to others, tiis researcher believes 
some credit should be given for comment lines. However, to 
keep verbosity out of programs due to comment lines and to 
be consistent with the credit given for reused code 
[Sef. 16 ], they should only count as twenty percent and then 
should be a full eighty characters long. Lines that are 
executable or data declarations aid the like should be 
counted fully as one line. 
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If LCC is used as a measure for program length, it 
should be measured as a block of LOC, haing at least one 
hundred lines a rd not mire than one thousand lines per 
block. Thera are two reasons to do this. First, each block 
of LOC can have a time value association. Phis allows 
developers to speak in terms of time per block of code. 
This is valuable when trying to estimate the time required 
to develop a program estimated to be some number of blocks 
of code long. Second, code must have an intrinsic quality. 
It makes little sense to discuss one tested, debugged and 
documented LOC. But it does make sense to discuss a block 
of code with the same qualities. Phis tends to force the 
code to have some minimum level of quality. The quality 
requirement takes into consideration the time spent by the 
programmer in writing non-d elivered test code and debugging 
aids and in correcting logic errors. When LOC are reused 
the count value should be a percentage of one original LOC. 
Basili and Freberger [Ref. 16] use twenty percent in their 
research. This researcher recommends starting with twenty 
percent and then adjusting it according to the percentage of 
time required to locate reusable code instead of developing 
original code. 

E. MODULE AS PRODUCTS 

A module is a single, intellectually managable portion 
of a program which is separately compilable but which must 
have connections to other modules. Its size is variable but 
it contains only one compLete responsibility assignment of a 
program. It has only one entry point and one exit point and 
conforms to the permitted logic structures of structured 
programming. The responsibility assignments are determined 
during the design phase before any work on individual 
modules is begun. One of the key areas of modular design is 
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the selection of module contents based on the probability of 
change during the maintenance phase. In other words, assign 
rhose portions of programs/projects that are likely to 
change due to hardware or technology to their own respective 
modules. The advantage gained by this bit of overhead is 
found in the cost avoidance which foLlows during the mainte- 
nance stage, where up to seventy percent of a project*s 
costs lie. 

There is a paradox concerning maintenance and well 
written cods. If one measures productivity during the 
maintener.ee phase by cost per defect, a popular method, 
he/she will find that very poorly written code has a lower 
cost per defect than well written coda. This occurs because 
poorly written code has many errors which programmers must 
spend much time correcting. They, therefore, become very 
familiar with the program. The initial costs of relearning 
the pregram logic are spread over many errors in poorly 
written code, and over very few errors in well written code. 
However, the total cost of maintaining well written code is 
usually much lower. If one were to take the same well 
written modular code and compare it to the same well written 
non-moduiar code one should find: 1) fewer logic errors 
because of the extensive analysis during the design phase; 

2) it's easier to locate errors since they can often be 
traced to one module or at least to a branch of the program; 

3) it's easier to relearn the logic because of the need to 
only learn one or a few modules instead of the entire 
program. If any or all of these points are realized, FMSO 
could save a great deal in resources and improve customer 
satisfaction. Since FMSD presently must maintain over 9^00 
programs and respond to over 3203 program trouble reports 
(PI R) annually, any reduction in the cost, in time or money, 
on a per item basis could lead to significant savings and 
higher productivity ratings for program maintenance 
personnel. 
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The use of modular programming allows two other areas to 
be explored. The first is Parnas' [Ref. 17] idea of program 
raaiiies . The idea is to look at similarities in programs 
before looking at their differences and write generic 
programs based on the similarities. Then one adds the 
modules that will make the programs individualistic. In 
this way programmers can reuse existing code which is well 
tested and with which programmers are thoroughly familiar. 
This helps to reduce initial project development time and 
costs and to reduce maintenance costs. 

The second area is that which Zoll [Ref. 13 , p. 51] 
refers to as "metaprogramming". This is the use of data 
base libraries of modular code to build complete programs. 
The code is generic and the metaprogrammer merely researchs 
•‘•he data base and selects those modules which will meet the 
program logic. In this way programmers write much less 
original code. Lanergan and Poynton [Ref. 19] report that 
at Raytheon Company some new applications software have been 
developed forty times faster than by using traditional 
development methods. Reused modules have been averaging 
between forty a r.d sixty percent of the total LOC on major 
projects. The probability of inducing logic errors is 
reduced significantly and the probability of textual errors 
is also reduced due to the reduced amount of original code 
required. Kendall and Lamb [Ref. 2D], in their research at 
IBM, have reported data which shows that meta programming 
from a data base of modules should be seriously considered. 
Their study showed that eighty percent of the applications 
programming effort goes into production of programs whose 
used life is less than eighteen months. Therefore, any 
reduction in the effort to develop these programs and any 
reduction in the maintenance effort of these programs will 
provide a factor of four increase in the savings to be 
apolied to the maintenance of the twenty percent portion of 
the programs with a sigir.fi cantly longer life cycle. 
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The added attraction of modular code is the idea of 
completeness of the task. For a quality module to be deliv- 
ered for integration it must be: 1) documented; 2) coded in 
its entirety; 3) tested; and 4) debugged. These are much 
more difficult tc attain with LOC as the product. In parti- 
cular, it is very difficult to test a block of LOC since it 
relies heavily on the remainder of the code. Therefore, it 
can only be examined by inspection while modules can be 
inspected and machine debugged to a near zero defect condi- 
tion prior to integration. Although the documentation is 
nor vital for module delivery, it can be and should be an 
organizational requirement. 

The idea of designing projects, especially large ones, 
by dividing them into subprograms or modules is a very old 
concept in programming. During the 1970's it became a topic 
of high interest as a way to improve program reliability and 
maint ainablility . F.oss et al [Ref. 21], Liskov [Ref. 22], 

Crossman [Ref. 23], and Parnas * Ref . 24] [Ref. 17] wrote 
formidable papers extolling the virtues of modular program- 
ming. Yet t her e are many software development organizations 
■chat do not understand tie term, use or value of modular 
programming. The Department of Defense (DOD) appears to be 
one organization that does not fully understand the value of 
modularization and reusing code. lunson [Ref. 25] points 
this our in his short paper on reducing software costs by 
reusing code. Elshoff [Ref. 26] observed this problem at 
the General Honors Research Lab waere modularization not 
only appeared foreign to analysts and programmers but was 
viewed as detrimental to the software life cycle. The 
unfamiliarity with modularity is also present at the US 
Navy's Fleet Numerical and Dceanographic Center in some 
analysts and programmers. While this does not appear to be 
a problem at FMSO at the present, internal training may be 
required because of turnover of software development 
personnel. 
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This section concerns quality modules. These are 
modules that are coded in their entirety, tested, debugged, 
and documented. Each organization will have to set up the 
requirements for a countable module. This researcher recom- 
mends these attributes. They ensure attainment of the 
organization' s minimum quality standards and take into 
consideration the programmer's time in debugging and testing 
the module. When reused modules are a part of the delivered 
product they should be counted as a percentage of one 
module. Basili [Ref. 15 ] used twenty percent in his 
research. This is a good starting point. But if the 
organization finds that this is not an accurate percentage 
of the time required to develop original modules then the 
percentage should be adjusted accordingly. 

F. USER FUNCTIONS AS PRODUCTS 

The previous section dealt with functions based on 
program structure. This section deals with functions based 
on user requirements. While modules may vary in length by 
approximately one hundred lines of code, user functions can 
vary up to several programs, in example of this is a single 
entry accounting system. A company may want a system which 
performs several functions such as: ledger maintenance, 
invoicing, file maintenance, weekly reporting, etc. Each of 
these operations or functions, is a deliverable product to 
the customer as a part of the single entry accounting 
package. The quality of the entire package is determined by 
the customer satisfaction with each individual function. 
Albrecht, [Ref. 27] of IBM Corporation, uses this measure as 
the primary means of determining productivity ratings in the 
Applications Development group. He points out that one must 
be careful when using this measure or any other measure by 
keeping the major project objectives in perspective: on 
time, within budget, and a satisfied customer. 
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The specific product measure is what Albrecht calls a 
function value. The approach to determine the function 
value is to count the number of external user inputs, inqui- 
ries, outputs and master files that the project must develop 
as a part of the user requirements. An external user input 
is a communication from the user to the computer such as 
data forms, terminal screens, keyboard transactions, optical 
scanner forms and the like. These do not include inputs 
from tapes and data sets, which are considered as internal 
and part of the file count. Each of these user functions is 
weiqhted by a value designed to reflect that function’s 
value to the customer. Appendix I shows the details of 
determining the function value and Appendix II shows the 
details of determining the sizing and complexity of an 
entire project using function value components. Appendix II 
uses the same external user inputs and some internal inputs 
as components to compute the function points but also 
provides for the the computation of a development time esti- 
mation. It is important to note that Chrysler [Ref. 2] 
showed in an unrelated and independent study that these 
components were most significant in predicting development 
time . 

Albrecht's function value concept has several advantages 
over those measures previously mentioned. First, it is the 
only measure that deals specifically and directly with user 
satisfaction. The other measures virtually ignore the user 
between the functional specification phase and the implemen- 
tation phase. This method constantly works with the user. 
Secondly, since its focus is on user requirements and not 
on counting lines or blocks of code or modules, it tends to 
limit programmer gaming to improve his/her productivity 
rating artificially. Third, the measure breaks the project 
into user defined portions of importance. This focuses the 
effort towards teamwork since it requires the development 
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group to work as a team toward the production of functions 
to which the user has placed a wall defined importance. 
Lastly, the method provides more opportunity for a smoother 
evolution of change than the others. it focuses attention 
on the cost of each function and the effects on cost of 
mid -development changes. The constant attention to cost and 
user involvement provides a better nechanism to control the 
change process during development. it enables the planner 
to design for changes that may occur during the life cycle 
that may not te cost effective to include during the 
development phase. 

The function value concept has three disadvantages. 
First, there may some question as to whether to call a 
component an inquiry or an input. These are not always 
distinct items. If the weighting factors are different for 
each this may significantly alter the final function value. 
Second, users play a large part in determining the weighting 
factors, as it should be. Osers can be fickle, therefore, 
if is often extremely difficult to gat them to admit '•truth- 
fully" what they desire most. It is not so much that they 
are hiding information but that they don't really know what 
they want. Therefore, it requires talented interviewers and 
designers to determine the true desires of the users. The 
third disadvantage is that this measure is so good that 
managers may tend to rely on it too heavily. This is not 
the ultimate or universal measure but it is a good one. The 
other measures can give insights on products and produc- 
tivity that this measure can not. The function value is an 
aggregate measure and must be used as such. As Stevens 
[Ref. 28] of Performance Management Associates Inc. of 
Scottsdale (Az.) points out, there is no universal measure 
yet. We must use ail the imperfect measures available in an 
effort tc describe the programming activity. 
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G. TESTING, INTEGRATION, AND IMPLEMENTATION 



One of the concerns of managers, when discussing 
programmer productivity, is how to incorporate non-delivered 
code in the calculation of productivity. The non-delivered 
code consists of test cods, debugging aids and incorrect 
code. The incorrect cods is a function of the programmer's 
skill and is a penalty to his/her productivity rating. The 
test code and debugging aids are not mistakes. They are 
used by skilled programmers to ensare coding guality and 
correctness. There has been some concern that the 
programmer should have this code incLuded with the delivered 
code for productivity calculations. This researcher does 
not concur that the test code and debugging aids should be 
included. The programmer's job is to deliver code that 
meets the specifications. The only way to ensure the code 
actually meets those specifications is to perform some type 
of test. Test code and debugging aids are tools of the 
programmers just as milestones and management/support are 
tools for others in the software development arena. They 
are a necessary overhead which programmers must employ if 
they are to deliver the quality products discussed 
pre viously. 

The integration, testing and implementation phase of 
software development utilizes approximately forty percent of 
the project's resources [3ef. 37 ,p.18]. Intuitively, one 
would think that an area which uses so much of the resources 
would be a prime place to do some productivity research. 
This, unfortunately, is not the case. One of the prime 
reasons has been the inability of the industry to determine 
the role these activities play. Specifically, there is a 
question as to whether testing is a part of development or a 
part of quality assurance. If it is part of quality assu- 
rance then it is an overhead and not a productivity concern. 
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If it is a part of development then the product is tested 
and acceptable code. But what determines how productive the 
testing is? The time expended in tasting does not help to 
determine the productivity of testing because the time used 
in testing is a function of the nest plan and the number of 
defects found. Defects found does help to determine produc- 
tivity. It shows either poor design, poor programming, poor 
quality assurance practices or any combination thereof. 

Integration is left with the same type of problems. 
This activity takes project portions, modules, LOC, or 
programs, and brings them together to form a cohesive and 
integrated product. But if there are major difficulties 
encountered are they the the fault of the integrators? 
Probably not. The fault probably lies with the designers or 
the programmers. 

The manager must be aware of the problems that develop 
during this phase and keep records of them. Though there 
were no conclusive reports found on how to deal with the 
information, the consensus from the literature is that it 
must kept in a data base for later study and consideration. 
The science of software development has net progressed far 
enough to completely handle the test, integration and imple- 
mentation problem. Most researchers are of the belief that 
if we get control of the development process in a scientific 
way these problem areas may disappear. 

H. DOCUMENTATION 

The primary belief in the indusrty and particularly in 
DOD is that software development projects have two separate 
Products: program code and program documentation. This is 
an extremely short-sighted but understandable belief. As 
long as software development is viewed as having two 
products, this belief presents the opportunity to discard 
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one . 



Since -he program is what is wanted, all too often the 
documentation is reduced in an attempt to reduce development 
costs. The view that there are two products and the prac- 
tice of reducing the documentation thrive on the belief that 
software development and software maintenance are not 
related. This is not true. The documentation is required 
to learn the program logic and coding structure. A software 
project that was poorly designed and poorly or not 
documented is extremely difficult and much more costly to 
maintain than one that was well designed and well docu- 
mented. Nearly every other industry (i.e. automobile, 
electronics, machine tools, etc.) chat produces a complex 
product provides documentation on tie logic and design of 
that product so that maintenance personnel can provide 
quality and cost effective maintenance. Thera is no reason 
■co believe chat the software development industry should be 
any different. 

This researcher believes that documentation is not a 
separate product but an integral part of all well developed 
software projects. This chapter consistently discussed 
fully coded, well documented quality software. It should be 
intuitively obvious that a program that does not operate 
properly is of little or no value. And that one that oper- 
ates properly but is difficult to understand and maintain 
because of poor documentation is of nuch less value than one 
wich superior documencacion . Thus, the documentation has no 
specific measure of length only one of quality. Ic is a 
problem for the developers and quality assurance experts to 
ensure chat che documencacion is provided and adequate in 
describing the program logic and coding structure of the 
pro jecc. 
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17. THE MEASURES 



During the research for this paper it was noted that 
there is a great deal of misunderstanding both in the liter- 
ature and in the industry about programming and software 
development productivity. The raisun derstanding lies in the 
area that, when questioned about the product that is 
produced, one will receive quizzical looks or long spells of 
silence. People immediately want to jump to discussions on 
complexity, language, tools or the development environment. 
These have little to do with calculating productivity. 
Their roles are as parameters within which one must analyze 
the specific productivity rating. This is not to belittle 
the importance of these areas. It is simply a matter of 
organizing one's thoughts. One can not intelligently speak 
of improving productivity until one first has a quantitative 
measure and secondly a description of the environment. Too 
often people in the industry look at the environment not 
only first but exclusively. Without a product definition 
and the measure, the environment cannot be understood. 

Productivity has two components: outputs and inputs. 
The outputs, locsely defined, are the products previously 
discussed: projects, programs, functions points, modules, 
and LOC. They are dependent on the corporate hierarchical 
level and the philosophy used for software development. The 
inputs vary considerably depending upon which productivity 
measure one is interested. The most common input used is 
the person-month, 160-175 hours. This can be broken down 
into its various parts by programmers, management/support, 
systems analysts, and program analysts. But there are other 
inputs that may be worth considering such as CPU time or 
terminal connect time. Though, these are rarely if ever, 
considered. 
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A. LOC PER PROG RAH MER-HONT H 



The most common measure used for assessing productivity 
throughout the industry is LOC per programmer-month. Though 
a very popular measure, it is not very good. Since it is 
based on LOC it is subject to the Line counting variations 
mentioned in the previous chapter. This variation can be 
limited, . to a certain extent, by setting organizational 
standards as rec cmmended earlier. This would permit consis- 
tency in the organization but not across the industry. 
Recall, one of the reasons for measuring is to make compari- 
sons across organizational lines. As long as there are 
variations in the definitions of components no intelligent 
comparisons can be made. 

LOC per programmer-month is ineffective for noncodinq 
tasks* The tendency when computing this measure is to use 
pro gr ammer- month as the total development time which 
includes these nonceding tasks of design, documentation, 
testing and management/support. Since no coding is going on 
during these stages it makes little sense to include them in 
the coding effort. Therefore, that would imply that this 
measure should be used only for the coding phase. Of 
course, that focuses attention on the coding task exclu- 
sively, which is a minimal portion of the software 
development effort. 

Finally, this measure tends to penalize high-order 
language (HOL) programs in favor of programs written in 
Assembler language. Jones [Ref. 29, p. 21] provided the 
example shown in Figure u. 1 , This is an example of the 
same program written in two different laguages. Two of the 
purposes of using HCL are to cut costs and improve produc- 
tivity. Sut the example shows the paradox of this measure. 
It appears that Assembler language is more productive than 
the HOL even though the HD L program took one month less to 
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Activity 


Assembler 

Language 


HOL 


Design 


4 weeks 


4 weeks 


Coding 


4 


2 


Testing 


4 


2 


Documentation 


2 


2 


Mgmt/Support 


2 


2 


Total Effort 


15 weeks 


12 weeks 




{4 months) 


(3 months) 


Lines of code 


2D 00 


500 


LOC per prog- non 


5 00 


167 


i 




— j 



Figure 4. 1 Assembler Language vs HOL. 

produce. Notice also that Jones used the term "programmer- 
month" to mean the entire program development time, a common 
practice, as mentioned earlier. The actual programming 
times were one month and one-half month for Assembler 
language and HOL, respectively. Even if this time frame is 
used, though, the Assembler language at 2000 LOC per 
programmer-month appears to be twice as productive as the 
HOL at 1000 LOC per programmer-month. This points out the 
problem of not being consistent about terms. Jones uses 
programmer-month to mean the entire development time which 
yielded an average productivity figure which included a 
period when no ceding was being done at all. Using the term 
strictly and comparing it to Jones' usage leaves us with a 
four to one difference in productivity for Assembler 
language and a six to one difference in productivity for the 
HOL . 
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B. MODOLES PER MONTH 



This particular measure was presented in a paper by 
Crossman [Ref. 23]. Surprisingly, tnis researcher cculd not 
find any other references that have attempted to duplicate 
his findings. Yet he pointed to several advantages which 
this measure and its methodology of program development 
support. 

Modular design programming tends to minimize the 
complexity of projects. Minimizing the complexity parameter 
allows the manager to reduce the number of variables he must 
consider when making productivity comparisons. The defini- 
tion of a module appears to be more consistent throughout 
industry than LOC which gives it a potentially much better 
comparative capability between organizations, provided the 
other organizations use this measure. The use of modules as 
a product provides a consistency throughout the development 
cycle. It includes the design, coding, testing, docu- 
menting, and management/support phases. Yet it can also be 
broken down into its individual component efforts to deter- 
mine which effort has the greatest impact on development 
time and the impact of each module on the project as a 
who le . 

C. FUNCTION POINT DELIVERED PER »ORK HOUR 

Albrecht [Ref. 27] discussed the effects this approach 
has on showing the relative productivities between 
languages, project size and various programming technolo- 
gies. The method focuses on the external attributes of a 
program and the work-hours contributed by both IBM and 
customer personnel assigned to work on the project. It 
covers all phases of the project. The goal of this method 
of measurement is to state development costs m terms of the 
work-hours used to design, program and test the applications 
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pro ject. Although there is not enough data available 
presently to give conclusive results, the report does indi- 
cate the capability to show the relative productivities of 
different languages and development technologies. This is a 
major advantage that is not possible with LOT and has not 
yet been explored using modules. 

D. SELECTED IHDUSTRY METHODS FOR MEASURING PRODUCTIVITY 

The preceding sections of this chapter discussed various 
methods used in research to study programmer productivity. 
Each method mentioned uses a ratio of outputs (project, 
program, specifications, nodules, LOT or function value) to 
inputs (person-months, programmer-months, or work-hours). 
Previous sections provided recommended definitions for 
selected output and input components. This section presents 
measures used by several prominant corporations that develop 
software . 

1 • ISM 



Measurement of programs is still a fairly subjective 
process. Se can measure size, based on 'lines of code' 
or 'number of statments', but acceptance of these 
measures is not universal. Acceptance of lines of code, 
as an example, seems to be based on the view that 
althcuch lines of code may oe an imprecise measure, it 
is something that can be enumerated, and until something 
better is discovered we will continue to use it. There 
is a veiled invitation aere to find something better, 
r Ref. 30 ,p. 3 72] 



This is the philosophy used to approach the 
measuring of programming activities at the Santa Teresa 
Laboratory of I3M. The "something better" that IBM has been 
trying to refine for the Last three to four years has been 
the software science metrics developed by Halstead 
(Ref. 31], Figure 4.2 shows the major elements in use by 
IBM (Ref. 32] [Ref. 30]. The philosophy for using software 
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Figure 4.2 Halstead Element Relationships. 



science metrics is built on zhe following beliefs. Firs-, 
in any given language, one type of program is no harder to 
code than another. The experience at Santa Teresa labora- 
zory over the last five years is that the only things that 
affect produczivity are the language and the tools used. 
They have found that HOL is about twice as productive as 
Assembler language. Second, aside from language, the 
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development tools are what affects programmer productivity. 
To this end, IBM has consistently aided to the "workbench” 
of their programmers^ They have provided on-line program- 
ming capabilities, given each programmer his/her own 
terminal m his/her office, provided a dedicated program 
development computer and various programming aids such as 
Script. Third, the definition of operators and operands is 
consistent across language barriers. This gives software 
science metrics a significant advantage over other measures. 
Additionally, IBM research has shown that the size metrics 
used by Halstead are as accurate as LOC for measuring 
program size. 

Since programming productivity is believed to be 
constant for all programmers, given the same environment, 
I3M has looked primarily at the difficulty metric. 
Difficulty is defined as a metric that expresses the diffi- 
culty of writing code. It takes into consideration decision 
nodes, the repertoire of operators used and how concise the 
usage of the variables is. The measure, then, also appears 
to be one for ease of reading. It loss not tell how diffi- 
cult. the program must be. It only tells how difficult the 
programmer made the program. High difficulty can come from 
poor programming skills, poor program structure, inexperi- 
ence with the language or the complexity of the algorithm. 
The value of this metric is three fold. It tends to indi- 
cate err cr- prone ness much earlier in the development cycle 
than traditional methods. Intuitively, the more difficult 
the program, the more error-prone it is. The measure can 
only be taken after coding has been completed but it can be 
calculated immediately following the first clean compile. 
There is no need to wait for testing. Secondly, it points 
out those programs which need rework due to high difficulty 
values. Third, it points out programmers who consistently 
have high difficulty values. This enables the manager to 
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ensure that the programmer receives added training in the 
techniques available to reduce program difficulty. IBM has 
found that the difficulty measure tends to range from three 
to eight. When ever they see that a difficulty measure 
exceeds five, they call the programmer in to have him/her 
recode the program to reduce the difficulty measure to five 
or less. If the programmer consistently delivers code with 
high difficulty measures he/she is provided aided training 
in techniques which can lower the program difficulty. 

All this only gives measures of the program not the 
prodcuctivity of the programmer. For IBM to determine that 
all programmers had the same productivity, they had to test. 
The test measure was and continues, on a minor basis, to be 
LOT per person-year. LOT is defined as data declarations 
and executable statments. The use of this measure, now, is 
only to check for changes in productivity due to new tools 
and for reasonable production rate relative to the industry. 
IBM recognizes the comparability problem of the LOC measure. 
However, the IBM perceived industry average ranges between 
800 and 2500 LOC per year, given the line counting varia- 
tions. They continue to measure productivity using LOC per 
aar.-year to ensure that IBM remains wihtin this range. 

2. Amdahl 

a. System Software 

Amdahl’s approach to systems software develop- 
ment is different from most of the industry. As a 
manufacturer of IBM compatible hardware and software, their 
approach is to use IBM software products and modify them to 
operate more efficiently on Amdahl hardware. This means 
placing ’’hooks" into the IBM software to operate special 
Amdahl procedures. Since their goal is develop more effi- 
cient software, these hooks must be minimal in both length 
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and interference with the existing software and logic. 
Amdahl places a much higher empaasis on quality than 
quantity. 

In this light, none of the previously discussed 
measures apply. Amdahl uses a management by objectives 
(M30) approach to measure performance. Their hiring prac- 
tices aim towards acquiring those programmers who are 
experienced, skilled and senior in the industry. The 
programmers are organized into groups of two to three 
assigned to one team leader. Each group has its own area of 
responsibility for program development/modification. The 
assignment of tasks and the time constraints are determined 
by mutual agreement between the manager and team leader. 
The schedules are recorded and each programmer is evaluated 
on his/her performance. The evaluation is discussed with 
the respective programmer at the periodic performance 
review. Since each group has specific areas of responsi- 
bility and those areas are limited, any trouble reports 
received are easily assigned to the group and/or individual 
responsible. These are also included in the performance 
review. This scenario does allow any specific measure to 
quantify programmer performance. However, the programming 
section is a small organization, 53-75 programmers, so they 
track the type of modification against the time required and 
the quality of the programming. They do not use any parti- 
cular measure outside of budget and schedule. 'Ref. 33] 

b. Applications Software 

Amdahl’s application program development is very 
similar to the systems software development in that they use 
M3D as the predominant measure. They do use LOC per 
programmer year to do some measuring but it has very little 
significance to the operation. L3C is defined as all 
programmer-original COBOL statments. So credit is given for 
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reused code, although, they admit some credit should be 
given. This wculd appear to discourage reusing code but 
their incentive, reward and penalty system provides the 
necessary encouragement. How the system functions was not 
specified. Management does require programmers to use data 
dictionaries, and code libraries are kept in an on-line data 
base. The primary measure used to measure performance is a 
review cf the programmer's schedule. The programmer submits 
a schedule of task accomplishment to the manager. The 
manager reviews it to ensure it is realistic and then 
compares the schedule to the task completion dates as the 
programmer delivers the assigned tasks. Here, as in systems 
development, the primary ingredient for measuring is 
programmer and manager experience. * Ref . 34] 

The measure used to evaluate maintenance 
programming is built arou.i d the number of trouble reports 
received. Each programming group is responsible for mainte- 
nance of its assigned software. Team leaders must emphasize 
high quality in the software to avoid having to reschedule 
programmers onto maintenance from development. This does 
net prevent errors but it does cut them down. The main 
emphasis from the Applications Programming Manager is to 
ensure as rapid a response time as possible on the trouble 
reports. The required turnaround time for trouble reports, 
presently, is not to exceed six montas. They use the turna- 
round measure because it tends to indicate to the users that 
the company is genuinely interested in the productivity of 
software maintenance. It also gives the respective managers 
an additional reason when requesting more resources. 
Finally, it gives a business value to organized maintenance 
because it forces the various managers to schedule resources 
for program maintenance. 
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Amdahl uses program packages predominantly in 
their applications programing section. These packages come 
with their own documentation which allows Amdahl to take 
take an approach significantly different from this research- 
er's view point. Amdahl believes program code and 
documentation to be separate and unegual products. This 
belief is made possible because they have programs that can 
analyte code and tell the programmer the structure of the 
code. therefore, they feel that program maintenance 

without the documentation is not as difficult one might 
assume. However, documenation is encouraged. The method 
used is to request documentation and to make it as easy to 
provide as possible. To make the documentation easier, it 
is all written on-line using Script and a variety of user- 
developed macros that provide some graphics to enhance the 
prose. The documentation guality is now much higher and the 
documentation is much easier for the programmers to deliver. 
[Ref. 34] 

3. Systems Development Cor Donation (S DC) 

SDC's cost estimating procedures use LOC and pages 
of documentation as the primary productivity inputs to 
compute costs. They categorize the various types of LOC 
(data definitions, executable statements, reused code, etc.) 
to determine the subtask cost for each activity. The LOC 
are weighted by an in-house complexity measure which 
includes parameters for program size, security, and reli- 
ability. Each productivity measure is computed relative to 
the type of program (real-time process control, interactive, 
report generator, data base control, etc.) that was 
produced. Documentation is mesured by pages produced per 
day per type of program. Although they call documentation a 
separate product, they consider all projects to be inte- 
grated packages of both software coda and documentation. 
[Ref. 35] 
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4 . TRW 

TRW uses a weighted LOC par man-month method to 
measure productivity. They reviewed Halstead’s metrics but 
concluded, as did IBM, that source L DC is equivalent to the 
size metrics developed from counting operators and operands. 
They do concede that the difficulty metric deserves more 
study but they have no resources ivialable at present to 
conduct such a study. They have found that weighting the 
LOC with an in house factor for complexity and reliability 
is sufficient. The LOC is defined as a delivered well docu- 
mented and well engineered line equal to a card image. The 
card image is an eighty character line. Comment lines are 
not included but all lines which hoLd "computing" informa- 
tion are (e.g. job control language, edit links, format 
statements, data declarations, executable statements, etc.). 
TRW defines a man-month, 152 hours, to include all personnel 
hours directly chargeable to the project. 

At present, TRW does not measure maintenance produc- 
tivity. However, the interview with Dr. Boehm [Ref. 36], 
recommenced the method discussed in his book So ftw are 
Erqi neeri nq Economics [Ref. 37]. This method equates the 
annual maintenance effort to the annial change traffic (ACT) 
multiplied by the estimated development effort. ACT is the 
fraction of the software produce's source instructions which 
undergo change during a typical year, either through addi- 
tion or modification. 

TRW includes documentation in its definition of a 
LOC. This corresponds with the philosophy of this 
researcher. TRW does not treat software code and documenta- 
tion as separate products but as integral parts of the 
software project. 
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V. CONC LtJSIOHS AND RECO 5 M ENDATIONS 



This paper has attempted to point out the major areas 
which must be explored in order to measure and discuss 
programmer productivity or software development produc- 
tivity. The manager must decide what level of the 
organization he wishes to measure. He then must determine 
what, specifically, the product is which that level is 
making. Before proceeding any further, he should examine 
the quality assurance procedures and practices to ensure 
that they are both in use and that they do establish and 
check for a minimum quality standard. From hers the manager 
can select the various inputs which he feels are relevant to 
study. The productivity rates he computes need to be stored 
in a data base so that they may be used as comparators 
against time and other organizations. Finally, each measure 
must be kept in the context of its environment. This condi- 
tion provides two functions. First, it keeps the measure 
meaningful. Second, by selectively changing one element of 
the environment at a time, the manager can determine cause 
and effect relationships that can lead to establishing the 
optimum software development environment. 

The LOC measures are poor for software development and 
lead to paradoxical conclusions in many instances. 
Remaining with any measure that uses LOC will tend to bind 
the organization to technologies requiring the development 
of totally original code on every project. This will tend 
to prevent the use of meta p rogr ammir.g and the development of 
program families. These programming technologies show 
significant promise to reduce development costs and improve 
programming productivity dramatically. 
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Modular measures provide the opportunity to explore and 
develop the meta programming practice. They also have over- 
heads that must be accepted as development personnel learn 
the technology, the aided effort required in the design 
phase, particularly for "small" projects, and the possible 
inefficient use of CPU time due to an increase in the number 
of LOC. These are small overheads to pay if the development 
time can be reduced by as much as Laaergan [Ref. 19] claims. 
The measure can be used in conjunction with any other 
measure to help define the programming activity better. It 
may be especially useful in conjunction with function 
points. 

In closing, it is apparent for the literature and the 
discussions with the selected industry corporations that 
there is no perfect and correct measure or method for 
measuring programmer productivity. however, the vital point 
to understand is that nearly all organizations do measure 
programmer productivity in some fashion. Several organiza- 
tions admit that their methods lack, some possibly important 
inpurs cr parameters. However, each organization does 
atzempc to measure productivity so that each can gain some 
understanding of the organization's particular environment. 
Wien an understanding of the environment, each organization 
and researcher is able to conceptualize the software devel- 
opment process so that the manager can make intelligent 
assertions about how it is affeczed. 
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APPENDIX I 



CP SERVICES 

FUNCTION VALUE INDEX WORKSHEET 



Datat 



Project I0 » m 



Project NaA«i_ 
Prepared byi 



Date: 



Reviewed by i_ 



Dete: 



p ro\cct S unjwuvt Start Pate End Date Work-Hours Function Points Delivered or Designed 
— — - — . - - {from calculation). 



function Points Calculation (Delivered or Designed) s 



r 



Allocation estimated by Project Manager 



Note: Definitions 

on back of fora. 



Delivered Delivered by Delivered 
' Delivered by Modifying Installing by Using 
I by New Existing and Testing a Code 

t Code 
I 



Code 



a Package Generator 



Totals 

(Identify 

Preponderant 

Language) 



Language 

Input* 

Outputs 

Files 

Inquiries 

Work-hours 

Design 

Implementation 



I 

I _ 
I - 

I - 
I - 
I 

I - 

L: 



x < 
" X s 
’ X 10 

I x 4 

Total 



Unadjusted 

Function 

Points 



tren .t. : (Estimate degree of influence for each factor) 



b*ckuf*. recovery, and/or 
system availability are provided 
by the application design or 
implementation. The functions 
may be provided by specifically 
deaigned application code or by 
use of functions provided by 
standard software. for example, 
the standard 1)13 backup and 
recovery functions. 

Data communications are provided 
in the application. 

Distributed processing functions 
are provided m the application. 

Performance oust be considered 
in the design or Implementation. 

In addition to considering 
performance there is the added 
complexity of a heavily utilized 
operational configuration. Tha 
customer wants to run the 
application on existing or 
committed hardware that, aa a 
consequence, will be heavily 
utilized. 



On-line data entry is provided in 
the application. 

On-line data entry is provided in 
the application and in addition 
the data entry is conversational 
requiring that an input trans- 
action be built up over multiple 
operations. 

Master file* ara updated on-line. 



Inputs, outputs, files, or 
inquiries are complex in 

this application. 



Internal processing is 
in this apflication. 



complex 



Degree of Influence on Function: 

0 None 3 Average 

1 Incidental 4 Significant 

2 Moderate 5 Essential 



Total Degree of Influence (N) 

Complexity adjustment equals (0.75 ♦ 0.0\ (N 0 

Unadjuated Total X Complexity Adjustment • Function roints Delivered or Designed 
X - 
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rwyflnltiona i 



General Instruction: 



Count all inputs , outputs, naster files, 
inquiries, and (unctions that arc Bade available 
to the customer through the project's design, 
programming, or testing efforts. Tor example, 
count the functions provided by an IUP, FDP , or 
Program product if the package was modified, 
integrated, tested, and thus provided to the 
customer through the project’s efforts. 



Work-hours r 



The work-hour a recorded should be the IBM and 
customer hours spent on the DP Services 
standard tasks applicable to the project phase. 
The customer houra should be adjusted to IBM 
equivalent hours conaidenng experience, 
training, and work effectiveness. 



Input, Count : 



Count each systea input that provides business 
function communication from the users to the 
computer system For example*. 



e data forms 
e terminal »cr«en* 



e scanner forms or cards 
• key«u transactions 



Do not double count the inputs. For example, 
consider a manual operation tnat takes data 
from an input term, to form two input screens, 
using a keyboard to form each screen before the 
entry key is pressed. This should be counted 
as two (2) inputs not five (5). 

Count all unique inputs. An input transaction 
should be counted as unique if it required 
different processing logic than other inputs. 

For example, transactions such as add, delete, 
or change may have exactly the same screen 
format but they should be counted as unique 
inputs if they require different processing 
logic. 

Do not count input or output terminal screens that 
are needed by the system only because of the 
specific technical implementation of the 
function. For example, DMS/VS screens, that 
are provided only to get to the next screen 
and do not provide a business function for the 
user, should not be counted. 

Do not count input and output tape and file data 
seta. These are included in the count of files. 



Output Count i 

Count each ayate* output that provides business 
function communication from the computer system 
to the users. For example; 



a printed reports 
• terminal screens 



a terminal printed output 
• operator messages 



Count ell unique external outputs. An output is 
considered to be unique if it has a format 
that differs from other external outputs and 
inputs, or, if it requires unique processing 
logic to provide or calculate the output data. 

Do not include output terminal screens that 
provide only a ample error message or 
acknowledgement of the entry transaction, 
unless significant unique processing logic 
is required in addition to the editing 
associated with the input, which was counted. 



Do not include on-line inquiry transaction 
outputs where the response occurs immediately. 
These are included in a later question. 



File Count? 

Count each unique machine readable logical 
file, or logical grouping of data from the 
viewpoint of the user , that is generated, 
used, or maintained by the system. For 
example; 



input card files 
disk files 



tape files 



Do not count inquiry transactions, 
covered in a subsequent question. 



These are 



Count major user data groups within a data base 
Count logical files, not pnysical data sets. 

For example, a customer file requiring a 
separate index file because of the access 
method would be counted as one logical 
file not two. However, an alphabetical 
index file to aid m establisning customer 
identity would be counted. 

Count all machine readable interfaces 
to other system as files. 



Inquiry Count ; 

Count each input/response couplet where an on- 
line input generates and directly causes an 
immediate on-line output. Data is not entered 
except for control purposes and therefore only 
transaction logs are altered. 

Count each uniquely formatted or uniquely 
processed inquiry which results in a file scare! 
for specific information or summaries to be 
presented as response to that inquiry. 

Do not also count inquiries aa inputa or 
outputs. 
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APPENDIX II 



Section 6.2 
12-31-78 

Customer : Project ID : 

Project Description: 



DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Prepared By: 



Date Prepared: 



When Prepared: (check one block) 

( ) Before any Phase Completion 

( ) Requirements Complete 

< ) External System Design Complete 

( ) Internal System Design Complete 



( ) Coding Specs Complete 

( ) Integration Complete 

( ) System Test Complete 

( ) System Demo Complete 



DESIGN PHASE 
SIZE AND COMPLEXITY 
FACTOR 

ESTIMATOR FORM 



DP SERVICES 

DATA PROCESSING DIVISION 
IBM CORPORATION 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6.2 
12 - 31-78 



QUESTION DEFINITIONS 



1. SCOPE OF THE INVOLVEMENT WITHIN THE COMPANY 

a. Company Functional Organizations: 

Identify the number of independent organizational entities which 
will be involved either directly or indirectly in the project 
For example, if the system includes two business functions 
inventory control and billing, at least two organizations 
probably would be involved. Direct involvement refers to actual 
participation in the requirement study or design. Indirect 
involvement refers to review and approval of the requirements or 
design. The organizations may be counted separately in each 
location. For example, if the accounting department has a 
subdepartment in each of three geographic locations, and if each 
must either be interviewed or included in the approval cycle, 
then the accounting function should be counted as three 
organizations rather than one. Always include the data 
processing organization. 

b. Company Locations: 

Identify the number of company locations that require travel for 
information, interviews or approvals. The primary location must 
also be counted. Each city involved would be a location. Where 
multiple locations exist in the same city, consider each as half 
a location. 

c. Number of people in the organizations involved: 

Identify the number of hundreds of people in each organization 
identified in question la) above. For example, a project 
involving two organizations, one with 135 people, and one with 50 
people would count as three hundreds of people. This provides a 
definition of complexity of interviews and requirements 
definition. 



2. FUtJCTICNAL SIZE OF THE APPLICATION 
a. Number of Major Subsystems: 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6.2 
12-31-78 



1. SCOPE OF THE INVOLVEMENT WITH THE COMPANY 



a. Number of company functional 

organizations involved: x 4 = 



b. Number of company locations 

involved: x 12 = 



c. Number of 100 (s) of people in 

the involved organizations: x 2 = 



FI 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6.2 
12-31-78 



In general , a major subsystem is equivalent to a major 
application or system function. Examples of subsystems within an 
Order Processing System might be: 

• Order Entry 

• Accounts Receivable 

• Inventory Update 

• Inventory Replenishment 

• Shipping 

• Recovery and Restart 

• Invoicing 

• Management Reporting 

• File Administration 

• File Conversion 

If you think that a function is logically separable and 
reasonably significant in size then count it as a subsystem. 

b. Number of External Inputs: 

This question addresses all system input vehicles that provide 
business function communication from the users to the computer 
system (e.g., data forms, terminal screens, keyboard 
transactions, optical scanner forms). It does not include 
internal inputs such as tape and file data sets. These are 
included in the count of files. It should not include input 
screens that are needed by the design only because of the 
specific implementation (e.g., DMS/VS screens that are only 
provided to get to the next screen but do not provide input of a 
business function or business information for the terminal user.) 

It should include the inputs associated with all the functions 
committed in the design. If such functions as File Conversion 
and Data Base Maintenance are to be supported their inputs must 
be counted even if they are used only once. 

On-line inquiry transactions should not be counted here since 
they are included separately in a later question. 

The objective of this question is to enumerate all unique inputs. 
An input transaction should be counted as unique if there is any 
possibility that it will require different processing logic than 
other transactions. For example, transactions which have exactly 
the same screen format and differ only in a code used to indicate 
transaction type (e.g., add, delete, change) should each be 
counted separately as unique transactions. 

c. Number of External Outputs: 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 
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12-31-78 



2. FUNCTIONAL SIZE OF THE APPLICATION 



a. Number of Major Subsystems: 



xlO = 



b. Number of External Inputs: 



x 3 = 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6.2 
12-31-78 



As with the External Inputs this question addresses all system 
output vehicles that provide business function communication from 
the computer system to the users (e.g., printed reports, output 
screens, hard copy terminal output operator messages). On-line 
inquiry transactions, where the response occurs immediately on- 
line should not be included in this count. However, printed 
reports which are triggered by off-line or on-line inquiries 
should be included in this count. The count should not inlcude 
output screens that are needed by the design only because of the 
specific implementation (e.g., DMS/VS screens that are only 
provided to get to the next screen but do not provide a business 
function or business information for the terminal user.) 

An output is considered to be unique if it has its own format 
which differs from other external outputs, or if it requires 
unique processing logic to provide or calculate the output data. 

d. Number of Files: 

This count should include each planned unique machine readable 
logical file, or logical grouping from the viewpoint of the user, 
that is to be generated by or input to the system (e.g., card 
types, data base files, disk files, tape files). This question 
is oriented toward logical files not physical data sets. For 
example, a customer file requiring a separate index file because 
of the access method chosen during design would be counted as 1 
logical file not 2. However, a special alphabetical index file 
to aid in establishing customer identity would be counted 
separately. 

This count should include all machine readable interfaces to 
other computer systems. 

e. Number of On-line Inquiry types: 

This question addresses conversational input/response couplets 
where the on-line input generates and directly causes an 
immediate on-line output. These couplets generally do not enter 
data except for control purposes and therefore alter only 
transaction logs. 

In determining this count consider each uniquely formatted or 
uniquely processed inquiry (input/response pair) which results in 
a file search for specific information or summaries of groups of 
information to be presented as output response to that inquiry. 

Inquiries should not also be counted as inputs or outputs. 
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SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 
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12-31-78 



V 



c. Number of external Outputs: 



x 3 = 



d. Number of Files: 



x 7 = 



e. Number of On-Line Inquiry Types: x 4 = 

F2 



Ll 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6*2 
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3. COMPLEXITY OF THE OVERALL DESIGN PHASE 

a. Customer Capability: 

Consider whether the customer has data processing or user 
capability that will provide a good environment for requirements 
definition and system design or whether his people will require 
more that normal explanation and justification for routine 
decisions. 

On the other hand does the customer have so much expertise that 
his design convictions will complicate the job beyond that 
normally expected, (e.g., an application well suited to IMS but 
the customer wants to develop his own TCAM data base system. ) 

Both situations would hinder the project, 

b. Existing Customer Function: 

Does the customer currently perform the business functions that 
are to be included in the system or is this a new business area? 

An example of a new function that would result in a "no’’ answer 
would be, an insurance company that does not currently handle 
group dental plans but wants to develop an automated system to 
process group dental claims so that they can compete for that 
type of business, 

c. Existing EDP System: 

If the answer to the previous question was No, then this question 
must also be answered No. If the customer currently is 
performing the majority of the business functions to be included 
in the system and a significant number of these are being 
supported by existing EDP System(s), the answer should be Yes. 
Otherwise, the answer is No. 

d. First of a Kind: 

Has this application ever been computerized before, anywhere? Is 
this the first attempt to automate a significant business 
function in the application? A Yes to either question should 
make this system the First of a Kind. 

e. Hardware and Software Operational Environment: 

This question is addressing the overall complexity of the 
estimated operational system. An example of a Simple system 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 
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zicq 

rgr 
. UO; 



3. COMPLEXITY OF OVERALL DESIGN PHASE 



a. Will the customer's capability hinder: 
No C0) f Yes (10) 



b. Existing customer function to 
be automated: 

No (10), Yes (0) 



c. Does an EDP system exist now 
to perform the function: 

No (6), Yes (0) 



d. Is this system the first of its 
kind anywhere: 

No (0), Yes (10) 
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DP SERVICES DESIGN PHASE 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 



Section 6.2 
12-31-78 



environment would be S/370 Models 115 or 125, DOS or DOS/VS and 
the IBM Standard TP and data base products that operate on that 
level CPU. 

An example of an In Between system environment would be S/370 
models 135 or 145, DOS, DOS/VS or OS/VS and CICS or DL/I or 
something equivalent. 

Large computers or more sophisticated operating System (e.g. , 
MVS) or TP or DB environment (e.g., IMS or TCAM) would be 
considered as Complex. Distributed processing and programmable 
terminals would also be considered complex.. 



4. SOPHISTICATION EXPECTED OF THE SYSTEM 

a. In answering the availability question consider how important it 
is that the system be kept available to the users. The whole 
data processing system including communications and terminals 
should be considered. Can work be postponed? 

Will components be duplicated to increase system availability? 
This can indicate critical availability. Will the system be 
designed to recover quickly from failure? This can indicate 
important availability. 

A batch system usually requires normal availability. A data 
collection system with non-perishable inputs, such as paper claim 
forms, might justify important availability. A passenger 
reservation system or bank funds transfer system might require 
critical availability. 

b. Will a major or important design consideration be, that each 
operation or function identified as critical have an alternate 
method. The alternate may involve manual operations and may take 
longer but the function is provided. 

c. Will the system contain data that must be protected against loss? 
Will the function require special recovery design in either 
procedures or system? If so, the answer is yes. 

d. Data Traffic Load or System Performance: 

In some systems, the volume of data to be handled is not a design 
concern. Other systems require special design considerations 
such as: use of file access optimization, simplified input 
notation, or extensive use of exception reporting. Transaction 
rates may be a problem in either on-line or batch systems. Large 
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e. Hardware and software system 
operational environment to be 
required by the application: 

Simple (0) , In-between (5) , Complex (10) 



F3 



4. SOPHISTICATION EXPECTED OF THE SYSTEM 

a. Availability is: Critical (8), 

Important (4) , Normal (0) 

b. Is an alternate method, for 
performing the functions of the 
system, non-routine consideration: 
No (0), Yes (6) 

c. Is system recovery or protection 
against data loss a non-routine 
consideration : 

No (0), Yes (5) 
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volumes of data in short periods (peak loads) or volumes of data 
large enough to cause machine availability problems are all 
considered data traffic considerations. 

System performance is often a significant design consideration in 
systems that are intended to handle large volumes of data. It 
can also be of major concern in the design of systems with 
relatively low transaction rates but with constraints (perhaps 
economic) in terms of the prescribed hardware and software 
environment. For example, there may be limitations on the size 
of main storage, control program multi -programming capabilities, 
or transmission line speeds. 

e. Nature of the Application: 

A batch system operates as a job shop, often scheduled. 
Transactions are typically batched external to the computer and 
periodically processed sequentially against the master files. 

An on-line system generally requires a more sophisticated 
man/machine interface than a batch system. It is generally a 
system where transactions are entered as they' are received with 
no opportunity for time saving sorting. The inputs are not 
perishable (i.e., they can be re-entered if necessary). An on- 
line order entry system, or an on-line stock location and 
inventory control system would be examples of on-line. 

A real-time system is similar to an on-line system in that it is 
available on demand, but it has an additional requirement to not 
postpone its main line processing. Response time is 
exceptionally important. Immediate processing and response is 
necessary to meet the functional requirements of the system. 
Process control, production test stand control, and airline 
reservation systems are examples of real-time systems where 
degraded performance may cause lost production or lost business. 



f. Processing Complexity: 

This question addresses the internal processing logic required to 
provide the majority of the proposed system functions. 
Straightforward logic would involve simple transformations or 
mapping from the system inputs or files to the system outputs. 

For example, a transaction is read, verified to a limited degree 
and used to update a simple master file or to generate a simple 
report. Processing is a straightforward set of pre-specif ied 
rules. Few, if any, data transformations are done. Outputs are 
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d. Is data traffic load or system 
performance an important 
design consideration: 

No (0 ) , Either (10) , Both (20) 



e. Nature of the Application: 

Batch (0) , On-Line (10) , Real-Time (20) 
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mostly collections in various sets, of established data from 
files. 

Complex should be checked if the system has a preponderance of 
exception processing resulting in many incomplete transactions 
that must be resolved later or again. Complex logic would also 
be the answer if there are many interactions and decision points 
and extensive logical or mathematical equations. In-between is 
used if it fails to meet either of the above definitions. 

g. Exception Correction: 

Systems which are designed primarily to process correct data and 
to detect and present bad or unusual data for manual review and 
correction are manual exception systems. If the system is to be 
designed not only to detect, but also, automatically to correct a 
significant number of unusual conditions, the system is an 
automatic exception system. This is true even if the options 
selected or corrections applied are to be reviewed and verified 
manually. 



5. KNOWLEDGE WE HAVE FOR THIS PROJECT 

a. Consider the Services Area in general and specifically the people 
who may influence the project through; 

• Project Management 

• Proposal Preparation 

• Systems Assurance 

• Project Team Performance 

Consider the Area's current knowledge and the available Industry 
knowledge. If none of the people in the performing Area have 
designed or implemented this type of application before, the 
answer should be Completely New. If informed consultation and 
review is available with people in the Area the answer should be 
Some Familiarity. If Services people, clearly expected to 
participate significantly in the proposal and project, are 
currently assigned to the performing Area and have recently 
performed on a similar project the answer may be Have Done 
Similar Job Once. 

b. To answer Extremely Thorough the proposal should contain a 
technical baseline that shows excellent understanding of the 
tasks in the Statement of Work. The Customer User, IBM Branch, 
and DP Services must have contributed and concurred with the 
approach. Everything else should be moderate unless we lack 
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'SS 



f. Processing complexity: 
Straightforward (0) , 

Complex (30) , In-between (15) 



g. Exception Correction is mostly: 
Manual (0), Automatic (20) 



F4 



5. KNOWLEDGE WE HAVE FOR THIS PROJECT 

a. How familiar is the proposed 

Services Area with this Application: 
Completely New (30), Some 
Familiarity (15) , Have done 
Similar job once (0) 
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customer agreement either through lack of contact or because of 
direct disagreement. 



6. READINESS TO PERFORM THIS PROJECT 

a. Consider the location of the project with respect to the home 
location of the people expected to work on it. Unless local 
commuting habits and ground rules indicate otherwise , travel of 
more than one hour each way to the work location should be 
considered Significant Commuting. 

b. Consider the proposed manning on the project. Normally the 
manning on DP Services projects comes from DP Services, the IBM 
Branch, or the Customer. If the manning is proposed with 
elements other than these, (i.e., subcontract or shop order) mark 
an equivalent answer from the viewpoints of Project Management 
control and the resource's ability. 

c. All temporary or permanent moves of project team members should 
be considered whether they involve IBM people or customer people. 



THE SIZE AND COMPLEXITY FACTOR COMPUTATION: 

To compute the Design Phase Size and Complexity Factor that will be used 
to validate the task-by-task estimate follow these steps: 

1. Review and sum up the weighted answers to the questions to 
determine factors FI through F6. 

2. Enter FI through F6 and evaluate the equations on page 19. 

3. Sum the results of (1), (2) and (3) to obtain the Design Phase 
Size and Complexity Factor. 



ESTIMATE VALIDATION: 

Use the Design Phase Size and Complexity Factor and the plots provided 
in Section 6.2 to determine the average number of hours that the 
standard tasks took on completed DP Services projects with similar 
Design Phase Size and Complexity Factors. Enter these hours in the 
appropriate blanks on page 20. 

If the data is sparse, the information on each standard task may not be 
provided as a separate number. However, the hours spent on that task 
are in the totals and in the associated standard task. (e.g^ , the hours 
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b. Services Preproposal Analysis: 

Extremely thorough (0) , 

Moderate (10) , No customer agreement with 
approach (20) 



F5 



6. READINESS TO PERFORM THIS PROJECT 

a. Where is project to be located: 

No unusual commuting (0) , 

Significant Commuting (5), 

Temporary or permanent moves 
required (10) 

b. Manning: 

All Services (0), Mixed IBM Manning (5), 
Customer and IBM Mixed (10) 

c. Number of temporary and permanent 
moves required 
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for implementation planning may not be separately identified, but they 
would be in the internal system design task and in the total hours. ) 

Map the task-by-task estimate into the same standard tasks and compare 
the estimates. The Proposal Manager should analyze and explain any 
differences or make the appropriate adjustments in the task-by-task 
estimate and the proposal. 



FEEDBACK PROJECT RESULTS: 



After the project is completed and the PCAR is available, adjust the 
Design Phase Size and Complexity Factor. The factor needs to be 
adjusted to account for changes (approved PCR(s)) that occurred during 
the project. This adjustment provides a factor that should be related 
to the completed project's results: 



Original S l C - The original size and complexity factor computed 

at proposal time on page 19. 

Change Hours - The total estimated hours of approved changes 

taken from the PCAR- 



Total Hours 

Multiplier - The current factor multiplier for the total 

hours plot in the design phase estimator. 



Adjusted S ( C - The size and complexity factor used for project 

feedback of results adjusted for the approved 
changes. 

Adjusted S £ C = Change Hours ♦ Original S £ C 

Total Hours Multiplier 



The results of the completed project standard tasks and the delivered 
reports are also taken from the PCAR. If the project does not represent 
a complete design phase, the numbers must be used with care. (e.g. , a 
requirements only design phase can give a good requirements number. It 
certainly won't give any design numbers. Less obviously, it won't give 
any management numbers or total hours numbers either) . 
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DP SERVICES DESIGN PHASE Section 6.2 

SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 12-31-78 

THE SIZE AND COMPLEXITY FACTOR COMPUTATION: 

1. Orientation Factor: 

( ) (100 ♦ ( ) ♦ ( )> x .9/1000 = 

FI F5 F6 

2. Requirements Analysis Factor: 

( ) (100 ♦ ( ) ♦ ( ) 

F2 FI F3 

♦ ( )/10 ♦ ( ) ♦ ( )) x .6/1000 = 

F4 F5 F6 

3. System Design Factor: 

( ) (100 + ( )/2 + ( )/3 

F2 F3 F4 

+ ( )/4) 1.7/1000 = - 

F5 

Size and Complexity Factor = 

Sum(l) , (2) , (3) 
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SIZE AND COMPLEXITY FACTOR ESTIMATOR FORM 
ESTIMATE VALIDATION: 



From From 

S & C Factor Task-By-Task 

Total Hours 

System Design 

External System Design 

Internal System Design 

Implementation Plan . 

Requirements Definition 

Orientation 

Management 

System Design Report Size 

Requirements Report Size 
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Comments 
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